Claim Rejections - 35 U.S.C § 102 

Claims 1, 3, 4, 6 and 9-13 are rejected under 35 U.S.C. § 102(e) as being anticipated by 
Donahue et al (6,101,180). Donahue et al is newly cited by the Examiner. For at least the 
following reasons, this rejection is traversed. 

Donahue et al is newly cited against claim 1 on the basis of its illustration of a satellite- 
based network in Fig. 2 and its illustration of an IP Multicast Switch (IPMS) as illustrated in Fig. 
5. The Examiner's rejection is based on two key assertions. First, the Examiner asserts that 
IPMS 120 acts as a "route server" that maintains routing tables for establishing multicast 
sessions for a plurality of routers 170, as described beginning at col. 12, line 40. Second, the 
Examiner asserts that the NOC 472 as illustrated in Fig. 15 acts as the claimed "controller." 
Applicants respectfully submit that the Examiner's analysis supporting each assumption is 
flawed in that there is no basis for asserting that IPMS 120 and NOC 472, whether considered 
independently or in combination, can meet the limitations of claim 1, the only independent claim 
in this group of rejected claims. Accordingly, Applicants' comments will be focused on this 
claim and the clear bases for distinguishing it from the limited teachings of the reference. 

The present invention provides a bandwidth-efficient technique for routing multicast IP 
traffic over meshed satellite networks where the multicast routing protocols are established and 
stored in a centralized route server . As explained in previous amendments, with reference to Fig. 
1 of the present application, the route server 40 is a unique system component that allows 
external routers 52, 54, 58 to participate in multicast routing sessions on the basis of routes 
established and stored by the centralized route server 40. Thus, the system has the following 
features: 

• A common route server establishes multicast routing sessions for multiple external 
routers; 



• External routers attached to clients are operative to convey multicast routing packets 
to the common route server and to receive updated routing information from the route 
server; 

• The route server contains a multicast group table that stores all of the routing 
information for all of the external routers that it services; and 

• Routing information is exchanged only between each router and the route server 40, 
and not among all routers. 

Thus, in claim 1, there is a clear requirement for network arrangement having (1) a 
plurality of terminals for providing IP multicast services via at least one local router, (2) a route 
server that communicates with the plural local routers and establishes and maintains routing 
information for the plural local routers , and (3) a controller operative to allocate broadcast bursts 
to the terminal based on requests from the terminals via the local routers. The route server that 
performs the recited function is not found in the prior art. Similarly, for method claim 14, the 
fundamental features of (1) establishing and maintaining routing information for a plurality of 
routers in a common route server , (2) allocating TMDA slots to the terminals based on requests 
from the terminals via the route server and updating the routing information in the route server, 
and (3) broadcasting the IP multicast services over the slot according to the routing information 
in the route server are not in the prior art. 
Donahue 

Donahue et al does not anticipate the invention of claims 1 or 14 because it does not have 
any teaching of a route server, as claimed. Other related limitations also are missing, as 
subsequently discussed. 



The IPMS Is Not a Route Server 

The route server in the present invention has the express function of (1) establishing and 
(2) maintaining routing information for a plurality of local routers. This function defines the 
essential feature of a route server, that is, a device that centrally provides functional services to a 
plurality of routers so that they need not act individually. The Examiner relies on the illustration 
in Fig. 15 to show such feature in Donahue, particularly with respect to IPMS 120. However, 
with reference to Fig. 15, the IP multicast switch (IPMS) is coupled to the satellite 55 via a 
receive antenna 130 for reception of digital signals (TCP/IP). As described at col. 12, line 40, 
the IPMS 120 is multicast-enabled. Data received by the IPMS is output from an IP multicast 
filter (IPMF) 140 onto a LAN 145 that connects to a client 160 who wishes to receive a 
broadcast signal. The LAN 145 can be connected to the Internet through a router 170. However, 
all such connections concern broadcast data, and not routing information. Further, according to 
the patent, the EPMS 120 has four main threads, initialization, multicast packet handling, LAN 
packet handling and multicast client monitoring (col. 13, lines 1-47). These functions do not 
concern services provided to routers in the system, particularly with regard to routing 
information. These function are focused on the distribution of other data. Nothing in Donahue 
suggests that routing information may be established and maintained by the IPMS such that it 
performs as a route server. 

Donahue Does Not Centrally Maintain Routing Information 

As already noted, Donahue is focused on serving as a distributor of multicast 
transmissions. Donahue does not serve as a central store and distributor of routing information. 
As is clear from the description at col. 13, IPMS 120 can connect to multicast clients via one or 
more routers (col. 13, lines 48-65). This focus is on using the IPMS solely for distribution of 
multicast data, rather than routing information, as would be clear to one of ordinary skill in the 



art from the description in Donahue. This is in direct contrast to the features of the route server 
40 in the present invention where it is routing information, rather than multicast information, that 
is stored and distributed to other routers. 

This fundamental difference is already stated in the claims where the route server in 
claim 1 is stated to be in communication with a plurality of local routers for establishing and 
maintaining routing information for said plurality of local routers . Thus, the IPMS 120 cannot 
be the route server set forth in the claim, since it does not transmit routing information or 
otherwise maintain routing information. Indeed, there is no disclosure of stored routing 
information or even a structure ( such as routing tables) illustrated in the schematic 
representation of IPMS 120 in Fig. 15, nor is there any disclosure of such central storage medium 
for routing information elsewhere in Donahue. 

The NOC Is Not a Route Server or Controller 

The only disclosure of tables is with respect to NOC 472, which is a structure illustrated 
in Fig. 15. However, the Examiner asserts that this is a controller and, by this assertion, does not 
consider NOC 472 to be a route server. The Examiner's conclusion in this regard is correct since 
the NOC 472, as disclosed beginning at col. 21, line 22, contains a plurality of tables including a 
channel definition table (CDT), a carrier table (CT) and a channel cluster table (CC). These 
tables, as disclosed in the specification, contain channel, transponder, data rate and carrier 
information. These tables do not include any information with regard to routing information 
applicable to individual local routers. In other words, the CDT, CT and CC tables are concerned 
with the allocation of network resources related to the transponder units 445 of the satellite 55 
and are not concerned with the features of the present invention. In particular, there is no 
recognition that the central accumulation, storage and distribution of routing information in a 



route server, rather than the sharing of routing information between or among routers would be 
an advantage, as in the present invention. 

The NOC does not act as the claimed controller either, since it cannot allocate broadcast 
bursts based on requests from terminals via the route server. In the absence of a route server, as 
already noted, the NOC cannot have the claimed function. 

On the basis of the foregoing clear distinction between Donahue and the presently 
claimed invention of apparatus claim 1 and method claim 14, these claims clearly are 
distinguishable over the prior art patent to Donahue and cannot be anticipated. 

Claim Rejections - 35 U.S.C § 103 

Claims 2, 5 ,7, 8 and 14-16 are rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Donahue et al (6,101,180) in view of Liebowitz et al (5,812,545). This rejection is 
traversed for at least the following reasons. 

As a preliminary matter, Applicants note that Donahue et al fails to teach the fundamental 
principles of the invention, as recited in parent claims 1 and 14. Liebowitz et al does not remedy 
these deficiencies for the reasons given in the previous amendment where Liebowitz et al was 
successfully distinguished, as is evident by the Examiner's withdrawal of the previous rejection 
based on Liebowitz alone. 

The Examiner admits that Donahue et al fails to explicitly teach allocated bursts through 
the selection of one slot in a TDMA for broadcast communication. The Examiner looks to 
Liebowitz for a teaching of a PCD (a controller) which operates a switch to organize bursts in at 
least one of a plurality of time slots, with reference to col. 2, lines 48-52. The Examiner asserts 
that one of ordinary skill would be motivated by Liebowitz to deploy a digital wireless 
multiplexing system so that a communication channel (slot) is used only a fraction of the total 
number of time slots, in a periodic fashion. The Examiner concludes it would have been obvious 



to one of ordinary skill to incorporate the teachings of Liebowitz into the teachings of Donahue 
et al. 

As already noted, the Donahue et al patent fails to teach the fundamental principles of the 
present invention. The teaching of a PDC controller in Liebowitz does not remedy this 
deficiency. There simply is no route server taught in either reference. 

Moreover, Applicants traverse the Examiner's conclusion that Liebowitz et al may be 
combined with Donahue. There is nothing in Donahue that would lead one skilled in the art to 
adapt the TDMA features of Liebowitz to the Donahue architecture. Even if the references may 
be combined, again, the fundamental principles of the present invention are not found in the 
references. There is no teaching or suggestion that a centralized route server may act to 
assemble, store and distribute routing information for all routers in a network. Nothing in these 
references would teach one of ordinary skill to deviate from the conventional approach, as 
identified by the Applicants, for having individual routers exchange information with each other 
via the network and maintain their own tables. On the basis of the foregoing distinctions, 
Applicants respectfully submit that all the claims should be considered patentable. 

In view of the above, reconsideration and allowance of this application are now believed 
to be in order, and such actions are hereby solicited. If any points remain in issue which the 
Examiner feels may be best resolved through a personal or telephone interview, the Examiner is 
kindly requested to contact the undersigned at the telephone number listed below. 



The USPTO is directed and authorized to charge all required fees, except for the Issue 
Fee and the Publication Fee, to Deposit Account No. 19-4880. Please also credit any 
overpayments to said Deposit Account. 
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